Internet Engineering Task Force (IETF) G. Lozano 
Request for Comments: 7848 ICANN 
Category: Standards Track June 2016 


ISSN: 2070-1721 


Mark and Signed Mark Objects Mapping 
Abstract 


Domain Name Registries (DNRsS) may operate in special modes for 
certain periods of time, enabling trademark holders to protect their 
rights during the introduction of a Top-Level Domain (TLD). 


One of those special modes of operation is the Sunrise Period. The 
Sunrise Period allows trademark holders an advance opportunity to 

register domain names corresponding to their trademarks before names 
are generally available to the public. 


This document describes the format of a mark and a digitally signed 
mark used by trademark holders for registering domain names during 


the Sunrise Period of generic Top-Level Domains (gTLDs). Three types 


of Mark objects are defined in this specification: registered 
trademarks, court-validated marks, and marks protected by statue or 
treaty. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7848. 
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Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Domain Name Registries (DNRs) may operate in special modes for 
certain periods of time enabling trademark holders to protect their 
rights during the introduction of a Top-Level Domain (TLD). 


One of those special modes of operation is the Sunrise Period. The 
Sunrise Period allows trademark holders an advance opportunity to 
register domain names corresponding to their trademarks before names 
are generally available to the public. 


This specification was defined as part of the development of the 
ICANN Trademark Clearinghouse (TMCH). The ICANN TMCH is a global 
repository for trademark data used by DNRs, registrars, and trademark 
holders during the registration process of domain names. 


This document describes a mapping of the common elements found in 
trademark data. A digitally signed mark format is defined in order 
to support digital signatures on the mark. Finally, a mapping for 
encoding the signed mark document is defined. 


Three types of Mark objects are defined in this specification: 
registered trademarks, court-validated marks, and marks protected by 
statue or treaty. 


This specification is intended to be used in the gTLD space, but 
nothing precludes the use of this format by other entities. 


The detailed policy regarding the public key infrastructure (PKI), 
authorized validators, and other requirements must be defined based 
on the local policy of the entities using this specification. In the 
case of gTLDs, the detailed policy regarding the use of this 
specification is defined in the Rights Protection Mechanism 
Requirements document (see [ICANN-TMCH]), and the PKI is defined in 
[TMCH]. Implementations will need to implement such a PKI (or an 
equivalent) in order for the signatures defined in this document to 
have any useful semantics. 


The objects specified in this document can be referenced by 


application protocols like the Extensible Provisioning Protocol 
(EPP), defined in [RFC5730]. 
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1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


XML (EXtensible Markup Language) is case sensitive. Unless stated 
otherwise, XML specifications and examples provided in this document 
MUST be interpreted in the character case presented in order to 
develop a conforming implementation. 


"signedMark-1.0" is used as an abbreviation for 
"urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix 
"smd" is used, but implementations MUST NOT depend on it and instead 
employ a proper namespace-aware XML parser and serializer to 
interpret and output the XML documents. 


"mark-1.0" is used as an abbreviation for 
"urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" 
is used, but implementations MUST NOT depend on it and instead employ 
a proper namespace-aware XML parser and serializer to interpret and 
output the XML documents. 


2. Object Description 


This section defines the Mark and Signed Mark objects. Empty complex 
element types and abstract elements are defined to support additional 
definitions using XML schema substitution groups. Support for 
replacement through the XML schema substitution groups is included in 
the description of the objects. 


This section defines some elements as OPTIONAL. If an element is not 
defined as OPTIONAL, then it MUST be included in the object. 


The following elements are defined as telephone numbers: 
<mark:voice>, <mark:fax>, and <smd:voice>. The representation of 
telephone numbers in this specification is derived from structures 
defined in [ITU.E164.2005]. Telephone numbers described in this 
mapping are character strings that MUST begin with a plus sign ("+", 
ASCII value 0x002B), followed by a country code defined in 
[ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), 
followed by a sequence of digits representing the telephone number. 
An optional "x" attribute is provided to note telephone extension 
information. 


The following elements are defined as email addresses: <mark:email> 
and <smd:email>. Email address syntax is defined in [RFC5322]. 
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2.1. Holder and Contact Objects 


Marks are linked to Holder objects and optionally linked to Contact 
objects. This section defines the <mark:holder> and <mark:contact> 
objects. 


o The child elements of <mark:holder> include: 


* A <mark:name> element that contains the name of the individual 
holder of the mark. At least one of <mark:name> and <mark:org> 
MUST be specified, and <mark:name> is OPTIONAL if <mark:org> is 
specified. 


* A <mark:org> element that contains the name of the organization 
holder of the mark. At least one of <mark:name> and <mark:org> 
MUST be specified, and <mark:org> is OPTIONAL if <mark:name> is 
specified. 


* A <mark:addr> element that contains the address information of 
the holder of a mark. A <mark:addr> contains the following 


child elements: 


+ One, two, or three OPTIONAL <mark:street> elements that 
contain the holder’s street address. 


+ A <mark:city> element that contains the holder’s city. 


+ An OPTIONAL <mark:sp> element that contains the holder’s 
state or province. 


+ An OPTIONAL <mark:pc> element that contains the holder’s 
postal code. 


+ A <mark:cc> element that contains the holder’s country code. 
This is a two-character code from [1IS0O3166-2]. 


* An OPTIONAL <mark:voice> element that contains the holder’s 
voice telephone number. 


* An OPTIONAL <mark:fax> element that contains the holder’s 
facsimile telephone number. 


* An OPTIONAL <mark:email> element that contains the email 
address of the holder. 
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o The child elements of <mark:contact> include: 


* A <mark:name> element that contains the name of the responsible 
person. 


* An OPTIONAL <mark:org> element that contains the name of the 
organization of the contact. 


* A <mark:addr> element that contains the address information of 
the contact. A <mark:addr> contains the following child 
elements: 


+ One, two, or three OPTIONAL <mark:street> elements that 
contain the contact’s street address. 


+ A <mark:city> element that contains the contact’s city. 


+ An OPTIONAL <mark:sp> element that contains the contact’s 
state or province. 


+ An OPTIONAL <mark:pc> element that contains the contact’s 
postal code. 


+ A <mark:cc> element that contains the contact’s country 
code. This is a two-character code from [1IS03166-2]. 


* A <mark:voice> element that contains the contact’s voice 
telephone number. 


* An OPTIONAL <mark:fax> element that contains the contact’s 
facsimile telephone number. 


* A <mark:email> element that contains the contact’s email 
address. 


2.2. Mark 


A <mark:mark> element that describes an applicant’s prior right toa 
given domain name. 


A <mark:mark> element substitutes for the <mark:abstractMark> 
abstract element to define a concrete definition of a mark. The 
<mark:abstractMark> element can be replaced by other mark definitions 
using the XML schema substitution groups feature. 
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The child elements of the <mark:mark> element include: 


One or more <mark:trademark>, <mark:treatyOrStatute>, and 
<mark:court> elements that contain the detailed information of marks. 


o A <mark:trademark> element that contains the following child 
elements: 


* A <mark:id> that uniquely identifies a mark in relation to a 
repository of marks potentially maintained by more than one 
issuer. A <mark:id> value is a concatenation of the local 
identifier, followed by a hyphen ("-", ASCII value 0x002D), 
followed by the issuer identifier. 


* A <mark:markName> element that contains the mark text string. 


* One or more <mark:holder> elements that contain the information 
of the holder of the mark. An "entitlement" attribute is used 
to identify the entitlement of the holder; possible values are 
"owner", "assignee", and "licensee". 


* Zero or more OPTIONAL <mark:contact> elements that contain the 
information of the representative of the mark registration. A 
"type" attribute is used to identify the type of contact; 
possible values are "owner", "agent", or "thirdparty"”. 


* A <mark:jurisdiction> element that contains the two-character 
code of the jurisdiction where the trademark was registered. 
This is a two-character code from [WIPO.ST3]. 


* Zero or more OPTIONAL <mark:class> elements that contain the 
World Intellectual Property Organization (WIPO) Nice 
Classification class numbers of the mark as defined in the WIPO 
Nice Classification [WIPO-NICE-CLASSES]. 


* Zero or more OPTIONAL <mark:label> elements that contain the 
A-label form (as defined in [RFC5890]) of the label that 
corresponds to the <mark:markName>. 


* A <mark:goodsAndServices> element that contains the full 
description of the goods and services from the document 


certifying the registration of the mark. 


* An OPTIONAL <mark:apId> element that contains the trademark 
application ID registered in the trademark office. 


* An OPTIONAL <mark:apDate> element that contains the date the 
trademark was applied for. 


Lozano Standards Track [Page 7] 


RFC 7848 


O 


Lozano 


* 


Mark and Signed Mark June 2016 
A <mark:regNum> element that contains the trademark 
registration number registered in the trademark office. 


A <mark:regDate> element that contains the date the trademark 
was registered. 


An OPTIONAL <mark:exDate> element that contains the expiration 
date of the trademark. 


A <mark:treatyOrStatute> element that contains the following child 
elements: 


* 


A <mark:id> element; see definition in the <mark:trademark> 
section above. 


A <mark:markName> element; see definition in the 
<mark:trademark> section above. 


One or more <mark:holder> elements; see definition in the 
<mark:trademark> section above. 


Zero or more OPTIONAL <mark:contact> elements; see definition 
in the <mark:trademark> section above. 


One or more <mark:protection> elements that contain the 
countries and region of the country where the mark is 
protected. The <mark:protection> element contains the 
following child elements: 


+ A <mark:cc> element that contains the two-character code of 
the country in which the mark is protected. This is a two- 
character code from [1IS0O3166-2]. 


+ An OPTIONAL <mark:region> element that contains the name of 
a city, state, province, or other geographic region of 
<mark:country> in which the mark is protected. 


+ Zero or more OPTIONAL <mark:ruling> elements that contain 
the two-character code of the national territory in which 
the statute or treaty is applicable. This is a two- 
character code from [1S03166-2]. 


+ Zero or more OPTIONAL <mark:label> elements; see definition 
in the <mark:trademark> section above. 


A <mark:goodsAndServices> element; see definition in the 
<mark:trademark> section above. 
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A <mark:refNum> element that contains the serial number of the 
mark. 


A <mark:proDate> element that contains the date of protection 
of the mark. 


A <mark:title> element that contains the title of the treaty or 
statute. 


A <mark:execDate> element that contains the execution date of 
the treaty or statute. 


<mark:court> element that contains the following child elements: 


A <mark:id> element; see definition in the <mark:trademark> 
section above. 


A <mark:markName> element; see definition in the 
<mark:trademark> section above. 


One or more <mark:holder> elements; see definition in the 
<mark:trademark> section above. 


Zero or more OPTIONAL <mark:contact> elements; see definition 
in the <mark:trademark> section above. 


Zero or more OPTIONAL <mark:label> elements; see definition in 
the <mark:trademark> section above. 


A <mark:goodsAndServices> element; see definition in the 
<mark:trademark> section above. 


A <mark:refNum> element that contains the reference number of 
the court’s opinion. 


A <mark:proDate> element that contains the date of protection 
of the mark. 


A <mark:cc> element that contains the two-character code of the 
country where the court is located. This is a two-character 
code from [1IS03166-2]. 


Zero or more OPTIONAL <mark:region> elements that contain the 
name of a city, state, province, or other geographic region of 
<mark:cc> in which the mark is protected. In case 
<mark:region> is specified, a default-deny approach MUST be 
assumed regarding the regions of a country. 
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* A <mark:courtName> element that contains the name of the court. 
2.3. Signed Mark 


The <smd:signedMark> is a digitally signed XML document using an XML 
Signature [XMLDSIG]. The <smd:signedMark> XML document (SMD) 
includes a required "id" attribute of type XML Schema Definition 
(XSD) ID for use with an IDREF URI from the Signature element. The 
SMD might be transmitted as part of a protocol already based on XML; 
therefore, exclusive XML canonicalization as defined in [XMLC14N] 
MUST be used. 


A <smd:signedMark> element substitutes for the 
<smd:abstractSignedMark> abstract element to define a concrete 
definition of a signed mark. The <smd:abstractSignedMark> element 
can be replaced by other signed mark definitions using the XML schema 
substitution groups feature. 


The child elements of the <smd:signedMark> element include: 


o The <smd:id> element that uniquely identifies an SMD in relation 
to a repository of SMDs potentially maintained by more than one 
issuer. The <smd:id> value is a concatenation of the local 
identifier, followed by a hyphen ("-", ASCII value 0x002D), 
followed by the issuer identifier. 


o A <smd:issuerInfo> element that contains the information of the 
issuer of the mark registration. An "issuerID" attribute is used 


to specify the issuer identifier. The child elements include: 


* A <smd:org> element that contains the organization name of the 
issuer. 


* A <smd:email> element that contains the issuer customer support 
email address. 


* An OPTIONAL <smd:url> element that contains the HTTP or HTTPS 
URL of the issuer’s site. 


* An OPTIONAL <smd:voice> element that contains the issuer’s 
voice telephone number. 


o A <smd:notBefore> element that contains the creation date and time 
of the SMD. 


o A <smd:notAfter> element that contains the expiration date and 
time of the SMD. 
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o A <mark:mark> element that contains the mark information as 
defined in Section 2.2. 


The following is an example of an SMD: 


<?xml version="1.0" encoding="UTF-8"?> 
<smd:signedMark xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0" 
id="smd1"> 
<smd:id>0000001751376056503931-65535</smd:id> 
<smd:issuerInfo issuerID="65535"> 
<smd:org>ICANN TMCH TESTING TMV</smd:org> 
<smd:email>notavailable@example.com</smd:email> 
<smd:url>https://www.example.com</smd:url> 
<smd:voice>+32.000000</smd:voice> 
</smd:issuerInfo> 
<smd:notBefore>2013-08-09T13:55:03.9312</smd:notBefore> 
<smd:notAfter>2017-07-23T22:00:00.0002Z</smd:notAfter> 
<mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"> 
<mark:trademark> 
<mark:id>00052013734689731373468973-65535</mark:id> 
<mark:markName>Test Kamp: Validate</mark:markName> 
<mark:holder entitlement="owner"> 
<mark:org>Ag corporation</mark:org> 
<mark:addr> 
<mark:street>1305 Bright Avenue</mark:street> 
<mark:city>Arcadia</mark:city> 
<mark: sp>CA</mark:sp> 
<mark:pc>90028</mark:pc> 
<mark:cc>US</mark:cc> 
</mark:addr> 
</mark:holder> 
<mark:contact type="agent"> 
<mark:name>Tony Holland</mark:name> 
<mark:org>Ag corporation</mark:org> 
<mark:addr> 
<mark:street>1305 Bright Avenue</mark:street> 
<mark:city>Arcadia</mark:city> 
<mark:sp>CA</mark: sp> 
<mark:pc>90028</mark:pc> 
<mark:cc>US</mark:cc> 
</mark:addr> 
<mark:voice>+1.2025562302</mark:voice> 
<mark: fax>+1.2025562301</mark: fax> 
<mark:email>info@agcorporation.com</mark:email> 
</mark:contact> 
<mark: jurisdiction>US</mark: jurisdiction> 
<mark:class>15</mark:class> 
<mark:label>testandvalidate</mark: label > 
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<mark: label>test---validate</mark: label > 
<mark: label>testand-validate</mark: label > 
<mark:label>test-et-validate</mark: label > 
<mark:label>test-validate</mark: label> 
<mark: label>test--validate</mark:label> 
<mark: label>test-etvalidate</mark: label > 
<mark:label>testetvalidate</mark:label> 
<mark:label>testvalidate</mark: label > 
<mark:label>testet-validate</mark: label> 
<mark:goodsAndServices>guitar</mark: goodsAndServices> 
<mark:regNum>1234</mark: regNum> 
<mark:regDate>2012-12-31T23:00:00.0002Z</mark: regDate> 
</mark:trademark> 
</mark:mark> 
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
<SignedInfo> 
<CanonicalizationMethod 
Algorithm="http://www.w3.org/2001/10/xml-exc-cl4n#"/> 
<SignatureMethod 
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> 
<Reference URI="#smd1"> 
<Transforms> 
<Transform 


Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 


</Transforms> 
<DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> 


2016 


<DigestValue>wgyW3nZPoEfppt LhRILKnOQnbdtU6ArM7 ShrAfHgDFg=</DigestValue> 


</Reference> 

</SignedInfo> 

<SignatureValue> 
jMu4P £yQGiJBF OGWSEPFCJ jmywCEqR2h4LD+ge6X0+UnmKFFCuCZS/3SLKAx0L1w 
QDFO2e0Y69k2G7/LGE37X3v0flobFMloGwja8+GMVraoto5xAd4/AF7eHukgAymD 
o9toxoa2hO0yV4A4PmXzsU6S8 6XtCCUE+S/WM72nyn47z0UCzzPKHZBRyeWehVFQOt+ 
JYRMIAMZM57HHOQA+6eaxefRvt PETQUO4aVIVSugc40UAZZwhYcZrC6w0adqqqAZi 
30aPOBYbAVHMSmWSS+thFkbshomJfHxb97TD2gr1lYNrQIzqxk7WbHWy2SYdAtsI/Z 
ipJsXNa6osTUwl1CzA7 jfwA== 

</SignatureValue> 

<KeyInfo> 

<X509Data> 

<x509Certificate> 
MIIESTCCAzGgAwI BAgIBAJANBgkqhkiG9IwOBAQsFADBiMOswCOYDVOQQGEWJVUZEL 
MAkKGA1UECBMCQOEXFDASBgNVBAcTCOxvcyBBbmd1bGVzMRMWEQYDVQQKEwpJQOFO 
TiBUTUNIMRswGOYDVOQQDEXJJQOFOTiBUTUNIIFRFU1LQgQOEwHhcNMTMwMjA4MDAw 
MDAWWhcNMTgwMjA3MjM1OTU5S5WjJBsMOQswCOYDVQQGEWJVUZELMAkGA1UECBMCQOEx 
FDASBgNVBAcTCOxvcyBBbmd1bGVzMRcwF OYDVOQKEWSWYWxpZGF 0b3IgVE1DSDEh 
MB8GA1UEAxMYVmF saWRhdG9yIFRNQOggVEVIVCBDRVJUMIIBI jJANBgkqhkiG9w0B 
AQEFAAOCAQ8AMI IBCgKCAQEAO/cwvXhbVY10RDWWvoyeZpETVZVVcMCovUVNg/sw 
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WinuMgEWgVOFrz0xA04pEhXCFVv4evbUpekJ5buquUlgmOQyOsCKQLNHOHTAP jvkC5u 
pDqa51F1k0TMaMkIQjs7aUKCmA4RG4t TTIGK/EJR1ix8/DOgHYVR1dy1YPrMP+ou7 
5bOVnIos+HifrAtriv4qEqwLL4FTZAUpaCa2BmgxXfy2CSRObxD50r1lgcSa3vurh5 
sPMCNxqaXmIXmQipS+DuEBQMM8t ldaN7RYojUEKrGVsSNk5i9y2/7sjnlzyyUPf7v 
L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF 6scscQzZUTE1+hywIDAQABo4H/MIH8MAwG 
A1lUdEWEB/wQCMAAwWHQYDVROOBBYEFPZEcIQcD/Bj21Fz/LERuo2ADJviMIGMBgNV 
HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEWJV 
UzZELMAkGA1UECBMCQOEXFDASBgNVBAcTCOxvcyBBbmd1bGVZzMRMWEQYDVQQKEwpJ 
QOFOTiBUTUNIMRswGOYDVQQDEXJJQOFOTiBUTUNIIFRFU1LOQgQO0GCAQEwDgYDVROP 
AQH/BAQDAgeAMC4GA1UdHwOnMCUwI 6AhoB+GHWhOdHA6Ly 9 jcmwuaWNhbm4ub3Jdn 
L3Rt Y2guY 3JsMANGCSqGS Ib3DQEBCWUAA4 IBAQB2qSy7uit43cebKUKwWPrzz9y/ 
TkrMeJGK j040n+ 9uekaw3DJ5EqiOf/qZ4pjBD++oR6BICb6NQuOKwnoAz51E4Ssu 
y5+i930T3HfyVc4gNMIoHm1PS1917DBKrbwbzAea/ 0 jKWVzrvmV7TBfjxD3AQ01R 
bUSdBr6éI jbdLF1n0O5x0GOmrG7x50UPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk 
wydgyVYAty7otk1/z3bZkCVT34gPVF70SR6+OxUy8u0LzZF5A/beYaZpxSYG31lamL 
AdXit TWFipalGea91lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6Q0znX23FGk 

</X509Certificate> 

</X509Data> 

</KeyInfo> 

</Signature> 
</smd:signedMark> 


NOTE: The example shown above includes white space for indentation 
purposes. It is RECOMMENDED that SMDs do not include white space 
between the XML elements, in order to mitigate risks of invalidating 
the digital signature when transferring of SMDs between applications 
takes place. 


2.4. Encoded Signed Mark 


The <smd:encodedSignedMark> element contains an encoded form of an 
SMD (described in Section 2.3), with the encoding defined by the 
"encoding" attribute with the default "encoding" value of "base6é4" 
[RFC4648]. 


The following is an example of a <smd:encodedSignedMark> element that 
uses the default "base64" for encoding a <smd:signedMark> element. 


<smd:encodedSignedMark 
xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"> 

PD94bWwgdmVyc21vbj0iMS4wliBlbmNvZG1luZz0iVVRGLTgiPz4KPHNt ZDpzaWduZWRNYXJ 

rIHhtbG5zOnNt ZD0idxXJuOm11dGY 6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIigaw 

: (base64 data elided for brevity) 

PC9zbWO6c21lnbmVkTWFyaz4= 

</smd:encodedSignedMark> 
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2. 


E 


Formal Syntax 


Two schemas are presented here. The first schema is the schema for 
the Signed Mark object. The second schema is the schema for the Mark 
object. 


The formal syntax presented here is a complete schema representation 
of the object mapping suitable for automated validation of EPP XML 
instances. The BEGIN and END tags are not part of the schema; they 
are used to note the beginning and ending of the schema for URI 
registration purposes. 


1. Signed Mark Schema 


BEGIN 

<?xml version="1.0" encoding="UTF-8"?> 

<schema 
targetNamespace="urn:ietf:params:xml:ns:signedMark-1.0" 
xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0" 
xmlns:mark="urn:ietf:params:xml:ns:mark-1.0" 
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<annotation> 
<documentation> 
Schema for representing a Signed Mark object. 
</documentation> 
</annotation> 


<import namespace="urn:ietf:params:xml:ns:mark-1.0" /> 
<import namespace="http://www.w3.org/2000/09/xmldsig#" /> 


slos 

Abstract Signed Mark object for replacement via substitution. 

--> 

<element name="abstractSignedMark" type="smd:abstractSignedMarkType" 
abstract="true"/> 


S 

Empty type for use in extending for a Signed Mark object. 
--> 

<complexType name="abstractSignedMarkType"/> 


<element name="SsSignedMark" type="smd:signedMarkType" 
substitutionGroup="smd: abstractSignedMark"/> 


<element name="encodedSignedMark" type="smd:encodedSignedMarkType"/> 
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<complexType name="signedMarkType"> 
<complexContent> 
<extension base="smd:abstractSignedMarkType"> 
<sequence> 
<element name="id" type="mark:idType"/> 
<element name="issuerInfo" type="smd:issuerInfoType"/> 
<element name="notBefore" type="dateTime"/> 
<element name="notAfter" type="dateTime"/> 
<element ref="mark:abstractMark"/> 
<element ref="dsig:Signature"/> 
</sequence> 
<attribute name="id" type="ID" use="required"/> 
</extension> 
</complexContent> 
</complexType> 


<complexType name="issuerInfoType"> 
<sequence> 
<element name="org" type="token"/> 
<element name="email" type="mark:minTokenType"/> 
<element name="url" type="token" minOccurs="0"/> 
<element name="voice" type="mark:el164Type" minOccurs="0"/> 
</sequence> 
<attribute name="issuerID" type="token" use="required"/> 
</complexType> 


<complexType name="encodedSignedMarkType"> 
<simpleContent> 
<extension base="token"> 
<attribute name="encoding" type="token" default="base64"/> 
</extension> 
</simpleContent> 
</complexType> 
</schema> 
END 


3.2. Mark Schema 


BEGIN 

<?xml version="1.0" encoding="UTF-8"?> 

<schema 
targetNamespace="urn:ietf:params:xml:ns:mark-1.0" 
xmlns:mark="urn:ietf:params:xml:ns:mark-1.0" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<annotation> 
<documentation> 
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Schema for representing a Trademark, also referred to 
as Mark. 
</documentation> 
</annotation> 


SS 

Abstract Mark object for replacement via substitution. 

--> 

<element name="abstractMark" type="mark:abstractMarkType" 
abstract="true"/> 


k a 

<mark:mark> element definition 

--> 

<element name="mark" type="mark:markType" 
substitutionGroup="mark:abstractMark"/> 


l= 

Empty type for use in extending for a Mark object. 
--> 

<complexType name="abstractMarkType"/> 


<!-- 
<mark:mark> child elements 
--> 
<complexType name="markType"> 
<complexContent> 
<extension base="mark:abstractMarkType"> 
<sequence> 
<element name="trademark" type="mark:trademarkType" 
minOccurs="0" maxOccurs="unbounded"/> 
<element name="treatyOrStatute" 
type="mark:treatyOrStatuteType" minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="court" type="mark:courtType" minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 


<complexType name="holderType"> 
<sequence> 
<element name="name" type="token" minOccurs="0"/> 
<element name="org" type="token" minOccurs="0"/> 
<element name="addr" type="mark:addrType"/> 
<element name="voice" type="mark:e164Type" minOccurs="0"/> 
<element name="fax" type="mark:el64Type" minOccurs="0"/> 
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<element name="email" type="mark:minTokenType" minOccurs="0"/> 
</sequence> 
<attribute name="entitlement" type="mark:entitlementType"/> 
</complexType> 


<complexType name="contactType"> 
<sequence> 
<element name="name" type="token"/> 
<element name="org" type="token" minOccurs="0"/> 
<element name="addr" type="mark:addrType"/> 
<element name="voice" type="mark:el164Type"/> 
<element name="fax" type="mark:el64Type" minOccurs="0"/> 
<element name="email" type="mark:minTokenType"/> 
</sequence> 
<attribute name="type" type="mark:contactTypeType"/> 
</complexType> 


<complexType name="trademarkType"> 
<sequence> 

<element name="id" type="mark:idType"/> 

<element name="markName" type="token"/> 

<element name="holder" type="mark:holderType" 
maxOccurs="unbounded" /> 

<element name="contact" type="mark:contactType" minOccurs="0" 
maxOccurs="unbounded"/> 

<element name="jurisdiction" type="mark:ccType"/> 

<element name="class" type="integer" minOccurs="0" 
maxOccurs="unbounded"/> 

<element name="label" type="mark:labelType" minOccurs="0" 
maxOccurs="unbounded"/> 

<element name="goodsAndServices" type="token" /> 

<element name="apId" type="token" minOccurs="0"/> 

<element name="apDate" type="dateTime" minOccurs="0"/> 

<element name="regNum" type="token"/> 

<element name="regDate" type="dateTime"/> 

<element name="exDate" type="dateTime" minOccurs="0"/> 

</sequence> 
</complexType> 


<complexType name="treatyOrStatuteType"> 
<sequence> 

<element name="id" type="mark:idType"/> 

<element name="markName" type="token"/> 

<element name="holder" type="mark:holderType" 
maxOccurs="unbounded" /> 

<element name="contact" type="mark:contactType" minOccurs="0" 
maxOccurs="unbounded"/> 

<element name="protection" type="mark:protectionType" 
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maxOccurs="unbounded"/> 
<element name="label" type="mark:labelType" minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="goodsAndServices" type="token" /> 
<element name="refNum" type="token"/> 
<element name="proDate" type="dateTime"/> 
<element name="title" type="token"/> 
<element name="execDate" type="dateTime"/> 
</sequence> 
</complexType> 
<complexType name="courtType"> 
<sequence> 
<element name="id" type="mark:idType"/> 
<element name="markName" type="token"/> 
<element name="holder" type="mark:holderType" 
maxOccurs="unbounded" /> 
<element name="contact" type="mark:contactType" minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="label" type="mark:labelType" minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="goodsAndServices" type="token" /> 
<element name="refNum" type="token"/> 
<element name="proDate" type="dateTime"/> 
<element name="cc" type="mark:ccType"/> 
<element name="region" type="token" minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="courtName" type="token"/> 
</sequence> 
</complexType> 
Ses 
Address (<mark:addr>) child elements 
--> 
<complexType name="addrType"> 
<sequence> 
<element name="street" type="token" minOccurs="1" maxOccurs="3"/> 
<element name="city" type="token"/> 
<element name="sp" type="token" minOccurs="0"/> 
<element name="pc" type="mark:pcType" minOccurs="0"/> 
<element name="cc" type="mark:ccType"/> 
</sequence> 
</complexType> 
S 
<mark:protection> child elements 
--> 
<complexType name="protectionType"> 
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<sequence> 
<element name="cc" type="mark:ccType"/> 


<element name="region" type="token" minOccurs="0"/> 


<element name="ruling" type="mark:ccType" 
minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


<!-- 

Postal code definition 

--> 

<simpleType name="pcType"> 
<restriction base="token"> 

<maxLength value="16"/> 

</restriction> 

</simpleType> 


S 

Country code definition 

--> 

<simpleType name="ccType"> 
<restriction base="token"> 

<length value="2"/> 

</restriction> 

</simpleType> 


S 
Phone number with extension definition 
--> 
<complexType name="el64Type"> 
<simpleContent> 
<extension base="mark:el164StringType"> 
<attribute name="x" type="token"/> 
</extension> 
</simpleContent> 
</complexType> 


<a 

Phone number with extension definition 

--> 

<simpleType name="el64StringType"> 
<restriction base="token"> 


<pattern value="(\+[0-9]{1,3}\. [0-9] {1,14}) 2?"/> 


<maxLength value="17"/> 
</restriction> 
</simpleType> 


alee 
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Id type definition 
--> 
<simpleType name="idType"> 
<restriction base="token"> 
<pattern value="\d+-\dt"/> 
</restriction> 
</simpleType> 


<= 
DNS label type definition 
--> 
<simpleType name="labelType"> 
<restriction base="token"> 
<minLength value="1"/> 
<maxLength value="63"/> 


June 2016 


<pattern value="[a-zA-Z0-9] ([a-zA-Z0-9\-] * [a-zA-Z0-9]) ?"/> 


</restriction> 
</simpleType> 


œL 

Type used for email addresses 

--> 

<simpleType name="minTokenType"> 
<restriction base="token"> 

<minLength value="1"/> 

</restriction> 

</simpleType> 


<simpleType name="entitlementType"> 
<restriction base="token"> 
<enumeration value="owner"/> 
<enumeration value="assignee"/> 
<enumeration value="licensee"/> 
</restriction> 
</simpleType> 


<simpleType name="contactTypeType"> 
<restriction base="token"> 
<enumeration value="owner"/> 
<enumeration value="agent"/> 
<enumeration value="thirdparty"/> 
</restriction> 
</simpleType> 
</schema> 
END 
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4. IANA Considerations 
This document uses URNs to describe XML namespaces and XML schemas 
conforming to the registry mechanism described in [RFC3688]. IANA 
has registered two URI assignments: signed mark (signedMark-1.0) and 
mark (mark-1.0). 


O The signed mark namespace (signedMark-1.0) has been registered in 
the "ns" registry. 


URI: urn:ietf:params:xml:ns:signedMark-1.0 
Registrant Contact: IESG 
XML: None. Namespace URIs do not represent an XML specification. 


o The signed mark schema (signedMark-1.0) has been registered in the 
"schema" registry. 


URI: urn:ietf:params:xml:schema:signedMark-1.0 
Registrant Contact: IESG 
XML: See the "Formal Syntax" section of this document. 
o The mark namespace (mark-1.0) has been registered in the "ns" 
registry. 
URI: urn:ietf:params:xml:ns:mark-1.0 
Registrant Contact: IESG 
XML: None. Namespace URIs do not represent an XML specification. 


o The mark schema (mark-1.0) has been registered in the "schema" 
registry. 


URI: urn:ietf:params:xml:schema:mark-1.0 
Registrant Contact: IESG 


XML: See the "Formal Syntax" section of this document. 
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6. 


6. 


Security Considerations 


The security of a Signed Mark object depends on the security of the 
underlying XML Digital Signature (DSIG) algorithms. As such, all the 
security considerations from [XMLDSIG] apply here as well. 


The digital signature algorithm used in Signed Mark objects SHOULD be 
RSA-SHA256 [RFC6931]. The size of the RSA key SHOULD be at least 
2048 bits. A valid reason for choosing something else would be if 
RSA-SHA256 is deemed to not provide sufficient security. 


In the case of the ICANN TMCH, Signed Mark objects use the algorithms 
for digesting and signing recommended in this document. 


Signed Mark objects are used primarily for domain name registrations 
in gTLDs during the Sunrise Period, but other third parties might be 
using them. A party using Signed Mark objects should verify that the 
digital signature is valid based on local policy. In the case of 
gTLDs, the Rights Protection Mechanism Requirements document 
[ICANN-TMCH] defines such policy, and the PKI is defined in [TMCH]. 
Implementations will need to implement such a PKI (or an equivalent) 
in order for the signatures defined in this document to have any 
useful semantics. 
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